The present invention relates in general to client/server data communication systems and, more particularly, to a mail server included in an electronic mail system for use within a client/server data processing system. More particularly still, the present invention is directed towards a method and apparatus for defining a virtual domain in an email system.
Computer systems are well known in the art and have become a business staple and are also found in many homes. One feature available to the business world is that of using electronic mailing (email) to send and receive messages and other information to and from one another in a business setting. Similarly, home computers, such as desk tops or laptops, and other information devices, such as personal digital assistants (PDAs), allow telecommuting such that a user can connect to the user""s work server and down load and upload messages.
The email system allows clients of a network system, which is maintained by a server system, to send messages or data from one user to another. In order to minimize disk space and requirements as well as to maximize functionality and consistency of the electronic mailing engine used in the network system, the engine is typically located on the server and is merely accessed by a client in order to send messages or retrieve messages to or from another user or client on the server system. In this way, the client system typically allows the user to perform such operations as composing, updating, and sending messages while the server in such a system provides, in part, a server based message repository as well as providing message transmission and reception functions for the user at the client level.
A traditional email system 100, configured to operate in what is referred to as a consumer host mode, is illustrated in FIG. 1. The email system 100 includes a number of consumers and/or businesses 102-1 (xe2x80x9cabc.comxe2x80x9d) through 102-n (xe2x80x9cxyz.govxe2x80x9d) each of which is coupled to a service provider (SP) 104 (xe2x80x9cisp.netxe2x80x9d). Traditionally, the service provider (SP) 104 provides the various consumers and/or businesses 102 with just an unprotected IP router. The consumers and/or businesses 102 also operate and maintain their own application servers, including the email server, DNS server, and (if needed) LDAP server (not shown). For their own protection, each of the consumers and/or businesses 102 must operate through a firewall that filters out undesirable packets and insulates the organization""s internal network from the Internet. Notice that for many organizations, especially small ones, the email server may actually be the firewall system.
In the email system 100, those consumers and/or businesses 102-1 through 102-n who wish to read their mail must be connected to a service provider (SP) email server 106. The SP 106 also operates an email mailbox 108, and a DNS server 110 that provides the following services, a primary master server for the SP""s own domain (ISP.net), to designate as the root server for all consumers and/or businesses, act as a primary master server for consumers and/or businesses who do not wish to maintain their own public DNS server, and as a secondary server for consumers and/or businesses who prefer to maintain their own public server.
As part of the services provided by the SP 106, an SMTP relay host 112 that is managed by the SP offers offer a number of value added services, for which the SP may charge additional fees. In some cases, the relay host can be configured to allow the relay host to accept and hold the consumer""s email when their mail server is down. However, unfortunately, the relay host imposes a significant management burden on the SP since in some cases, consumer email may live on this server for an indefinite time raising issues of backup and failure recovery. If one of the consumer servers fails because of being swamped, for example, then the consumer""s email may roll over to the SP""s relay host. Because of this, most SPs do not offer a relay host for those consumers and/or businesses that are hosting their own email server. The SP also provides a directory service in the form of the LDAP Directory server that is located at the consumer""s site, which can be operated by the consumer. In this way, most organizations do not expose their LDAP servers to the public network for security reasons.
In the example shown in FIG. 1, a mail user in ABC, Inc. (which lawfully owns its DNS domain name abc.com, but relies on the ISP isp.net to host its email) desiring to send and receive mail uses the domain name username@abc.com even though his mailserver is really mailhost.isp.net. It also means that any user in the abc.com domain, connects to a mailhost in the domain abc.comxe2x80x94for example mail.abc.comxe2x80x94to access his/her mail.
Since the email system 100 requires a separate mail server to be supported by the SP 106 for each of the domains abc.com through xyz.gov, although well understood and easy to manage, the email system 100 is not cost effective for small domains. In addition, as the number of domains increases, the management of the individual services becomes increasingly unwieldy. Internet service providers (ISPs) have a growing interest in hosting email services for always larger and more numerous organizations. Many businesses see the ability to farm out email services as a very attractive cost-saving idea. It is therefore desirable that an email service provider be able to offer email services to multiple organizations each of which has their own virtual domain and to support the ability to define such domains in the directory and host them on a shared mail server. Thus, an email architecture that can support a single mail server which, in turn, can support many different domains associated with consumers and/or businesses is desirable.
However, when the users within a domain are granted a particular set of user level services, that set of user level services must be a proper subset of the associated allowed set of domain services.
Therefore, what is desired is a set of precedence rules that govern the granting of user level for a particular domain having a set of domain services.
To achieve the foregoing, and in accordance with the purpose of the present invention, methods for granting a user level service based upon a set of allowed domain level services is provided. In accordance with one aspect of the present invention, a method is disclosed where a requested user level service is granted or not based won a set of allowed domain level services. The user level service is requested and a subsequent determination is made whether or not the requested user level service is a member of a proper subset of the set of allowed domain level services. If the requested service is determined to be a member of the proper subset of allowed domain level services, then the requested user level service is granted. In so doing, the granted user level services becomes a member of a set of allowed user level services.